Referring to FIG. 1, a block diagram of a network according to the conventional art is shown. As depicted in FIG. 1, a plurality of organizations 105, 110, 115 are communicatively coupled by one or more communication channels 180 185, such as the internet or extranet. Each organization 105, 110, 115 typically comprises a plurality of client devices 120-150 communicatively coupled to one or more servers 155-175. The servers 155-175 provide one or more resources, such as execution of applications and/or storage of information.
A user on a client device 120-150 may be granted or denied access to resources of a particular server 155-175. In the conventional art, the client 120 logs-on to a particular organization's server 155, wherein the user provides a user name, password and/or the like. Based upon the user name, password and the like, the server 155 authenticates the client 120 and determines the client's 120 authorization to access particular resources.
If the client 120 then tries to access resource on another server 170, 175, establishing authentication and utilizing resources is problematic. The other servers 170, 175 do not know that the client device has been authenticated by a particular server 155. The other servers 170, 175 do not know that they can trust the authentication provided by the particular server 155. Furthermore, each entity 105, 110, 115 and/or server 155-175 may have a different login script, may require a different protocol, may store information in a different structure, format and/or the like. Therefore, the client typically has to sign-on to each server 155-175 separately.
For example, a user may wish to access resources on various entities 105-115 during the course of their work, such as using the internet to make travel arrangements. The user first logs-on to the company's network server 155 utilizing a client device 125. The user may manually or via a script, enter their user name and password in order to logon to the network server 155. The network server 155 provides an internet portal.
The user may then navigate using a browser to the website of an airline 115. The user will likely be required to enter a user name, password and the like to book a flight using a corporate account. Similarly, the user may then navigate to a car rental agency to reserve a rental car. Once again, the user may be requested to enter a name, password and the like to reserve the car. Similarly, the user may also navigate to a website of a hotel chain to reserve a room. Once again, the user may be requested to enter a name, password and the like to reserve the room. The need to logon to each entity's server 155 reduces the user's satisfaction and productivity.
The need to logon multiple times is not limited to multiple entities' servers 170, 175. For example, the user may login to their employer's network server 155 to access the finance server 160. The user may again be required to enter a username, password and the like in order to enter expenses, such as meals, entertainment and gas, incurred during their business travel. The user may then wish to check their retirement account. Once again the user may be required to provide a username, password and the like to access the payroll server 165 in order to check their retirement account. In addition to reducing the user's satisfaction and productivity, the implementation of multiple logon scripts increases the cost of doing business.
Versions of single sign-on services have existed for several years. However, the conventional art single sign-on services are closed solutions that do not offer broad interoperability. Accordingly, the Security Assertion Markup Language (SAML) specification is intended to provide a solution allowing single sign-on for secure authentication and authorization.
SAML is an eXtensible Markup Language (XML) standard designed for business-to-business (B2B) and business-to-consumer (B2C) transactions. The SAML standard is designed for the exchange of secure sign-on information between a user, a relying party, and/or an issuing party. Furthermore, SAML allows issuing parties to use their own chosen methods of authentication (e.g., personal key identifier (PKI), hash, password, or the like).
In one implementation, a SAML-compliant service, called a relying party, sends a SAML request to an issuing party, which returns a SAML assertion. Assertions do not create a secure authentication. The security service is responsible for providing a secure authentication. Assertions are coded statements generated about events, such as authentication, that have already occurred, as when the user provided the correct user name and password, or the security mechanism granted specific permissions.
Referring now to FIG. 2A, an exemplary SAML request/assertion according to the conventional art is shown. As depicted in FIG. 2A, SAML requests and assertions 210 are transmitted within a SOAP envelope 215 via HTTP 220.
Referring now to FIG. 2B, an exemplary SAML data packet according to the conventional art is shown. As depicted in FIG. 2B, the data packet comprises an HTTP header 250, a SOAP header 255 and a SAML payload 260. An assertion or response is encoded into the SAML payload 260. A SOAP header 255 is then generated and attached to the SAML payload 260. An HTTP header 250 is then generated and attached to the SOAP header 255 and SAML payload 260. The SAML payload containing an assertion or request may comprise an issuer identifier, an assertion identifier, an optional subject, an optional advice, a condition, an audience restriction, a target restriction, and an application specific condition.
Upon receipt, the HTTP header 250 is processed to provide routing and flow control. The SOAP header 255 is then processed to provide information concerning the content of the payload and how to process it. The SAML payload 260 may then be processed to provide security information.